Some communication systems allow the user of a device, such as a personal computer, to communicate across a packet-based computer network such as the Internet. Such communication systems include voice over internet protocol (“VoIP”) systems. These systems are beneficial to the user as they are often of significantly lower cost than conventional fixed line or mobile networks. This may particularly be the case for long-distance communication. To use a VoIP system, the user installs and executes client software on their device. The client software sets up the VoIP connections as well as providing other functions such as registration and authentication. In addition to voice communication, the client may also set up connections for other communication media such as video calling, instant messaging (“IM”), SMS messaging, file transfer and voicemail.
One type of communication system for packet-based communication uses a peer-to-peer (“P2P”) topology. To enable access to a peer-to-peer system, a user must execute P2P client software provided by a P2P software provider on their computer, and register with the P2P system. When the user registers with the P2P system, the client software is provided with a digital certificate from a server. Once the client software has been provided with the certificate, then calls or other communication connections can subsequently be set up and routed between users of the P2P system without the further use of a server in the set-up. Instead, the client looks up the required IP addresses from information distributed amongst the P2P client software on other end users' computers within the P2P system. That is, the address look-up list is distributed amongst the peers themselves. Once the IP address of a callee's terminal has thus been determined, the caller's P2P client software then exchanges certificates with the callee's P2P client software. The exchange of the digital certificates (or user identity certificates, “UIC”) between users provides proof of the users' identities and that they are suitably authorised and authenticated in the P2P system. Therefore, the presentation of digital certificates provides trust in the identity of the users.
It is therefore a characteristic of peer-to-peer communication that, once registered, the users can set up their own communication routes through the P2P system in an at least partially decentralized manner based on distributed address look-up and/or the exchange of one or more digital certificates, without using a server for those purposes. Further details of an example P2P system are disclosed in WO 2005/009019.
VoIP or other packet-based communications can also be implemented using non-P2P systems that do use centralized call set-up, e.g. via server.
Sometimes software programs such as communication clients must respond to asynchronous events, specifically state and/or data changes due to external events such those that occur over a network. To convey these events to the end user, the program must refresh one or more user interface elements on screen. “Refresh” in this context means the process of reading a new data value and then redrawing the value in some user interface element on screen. Example: user A is chatting with user B. When user B sends data or goes offline, such changes must be shown by refreshing the user interface element corresponding to user B on user A's screen.
The most simplistic method is to refresh the user interface directly in response to receiving an indication of such an event. This works well in the common case, but if the rate of incoming event indications is very high then the user interface will be needlessly refreshed too often, causing a performance problem.
One solution to address this performance problem is to provide a periodic timer that fires at a constant interval, e.g. every 1 second. In some implementations, this timer may always be running, regardless of whether there are any incoming events or not. In other implementations, this timer may be enabled only during the period in which there are a rapid succession of incoming events. Either way, the refreshing is done on a simple periodic basis, sometimes referred to as polling.
Another solution is to provide a delay in which refreshing the user interface is put “on hold”. Refreshes occur again only until after the delay runs out. In this case, the refresh is not performed at all (i.e. is completely suspended) until the incoming activity has calmed by some amount.